[レポート] DOP201 AWSの「Infrastructure as Code」1年間の振り返り #reinvent

はじめに

AWS事業本部 梶原@福岡オフィスです。 ラスベガスで開催されているre:Invent2022に参加しています。 今回はこちらのセッションに参加してきたのでレポートしたいと思います。

※※※
本セッションレポートは、現地での聞き取りまた、Google翻訳, DeepL翻訳等を使用しつつレポートしております。
内容には十分注意して作成しておりますが、誤訳または誤って理解している部分がある可能性があることをご容赦いただければと思います。
※※※

セッション概要

AWSの「Infrastructure as Code」. 1年間の振り返り

概要

Join this session to learn about the new features and improvements for AWS infrastructure as code with AWS CloudFormation and AWS CDK.

本セッションでは、AWS CloudFormationとAWS CDKを使ったAWS infrastructure as codeの新機能と改善点についてご紹介します。

スピーカー

Ben Perak, Principal Product Manager, Amazon Web Services
Tatiana Cooke, Principal Product Manager, AWS

セッション動画

セッション資料

https://d1.awsstatic.com/events/Summits/reinvent2022/QTC202_Quantum-applications-and-taking-POCs-to-production.pdf

セッション内容

タイトル

Agenda

• Infrastructure as Codeを単なる自動化と結びつけて考えている
• サービスの基盤となっているCloudFormationの詳細について説明します。
• 企業によるインフラストラクチャの利用方法、スケールコード、ペルソナの進化、コードとしてのインフラストラクチャの業界のトレンドをいくつか紹介します。
• 多くのお客様がインフラストラクチャのコードを標準化して使用しており、ポリシーをコード化してチェックしています。
• 最後に、2023年にむけてどこに進もうとしているのかの洞察を提供します。

Waht is infrastructure as code?

• 最初からインフラストラクチャコードから始めたわけではなく、最初はコンソールを用いてサービスを作成してる
• 単一のワークロードをデプロイし、1人か2人で環境を管理していた環境はうまくいく
• 人数が増え、ワークロードが増えると、その管理は非常に難しくなる

• プロビジョニングとライフサイクルの管理を自動化する方法を探し始める
• 一貫性、再現性、セキュリティ、安全性、そしてデプロイメントを実現するために、インフラストラクチャのコードベースのソリューションに行きつくことになる

How customers use AWS infrastructtre as code

• インフラストラクチャのコードを使用する方法は、従来のCloudFormationだけではない
• CDKやSAMを使用して、CloudFormationのスタックに変換して使っている
• コントロールタワーのようなサービスを利用している場合もありますが、実際に行われているデプロイメントがコードとしてのインフラであることに気づいていない
• インフラストラクチャのコードを介してすべてが流れるというパターンに気づくと、ツールを用いて、ベストプラクティスのチェックを実装する方法を見出す
• これらのコードはオープンなプラットフォームである。
• さまざまなタイプのサービスを構築することを可能にする
• このツールを使用するお客様がますます増えていく。

AWS IaC portfolio at glance

• 最初のレイヤーはCloudFormationリソースレジストリと呼ばれるものです。
• テンプレートに必要なものを定義し、その定義を個々のサービスに対するAPI呼び出しのセットに変換できるようにするものです。
• リソース・レジストリはすべてイミュータブル（不変）です。これは私たちのコアとなるオーケストレーション・プロビジョニング・エンジンです。
• JSON/YAMLベースのテンプレート・アプローチを使ってコア・エンジンとやり取りします。
• CloudFormationの上に構築されたさまざまなCDKなどの抽象化を見ることができるようになりました。
• コントラクトプログラミングモデルや、TypeScriptやPythonを使ったオーサリングインフラ、特定の種類のワークロードをサーバレスで実現したい場合などです。 -インフラストラクチャのコードを実際にどのようにスケールアウトするかというデプロイメントと管理を顧客が行うのを支援しています。AWS protonやサービスカタログのようなものがそうです。
• 右側は昨年発表したもので、これはサービスが個別にAPIを制御している
• CloudFormationレジストリの上に構築された一つの標準APIモデルを作成する必要がある
• リソース・マネージャーとのやり取りはテンプレートを使って行っていました。これをオープンにして、お客様がレジストリと直接対話できるようなコントロール・APIを提供する

Importance of a resouce foundation

• サービスがインフラストラクチャのコードでカバーされていないなら、それは私たちの世界には存在しない
• 標準化されたインフラは、本番環境へのオープンアクセスに重点を置いており、本番環境から来るものはすべて、制限のあるコードでサポートされたサービスでなければ、使うことすらできない
• 新しいサービスの状態をすべて確実にサポートすることは、本当に重要なことと考えている
• 最も重要なことは、これは私たちが内部向けのサービスでAWSのためにこれを解決する方法だけでなく、業界全体のための責任あるものである
• 私たちの目標は、業界全体でこのリソースモデルを解決することです。

AWS IaC coverage update

• 私たちは標準的なリソースモデルを持っています。
• エンジニアの追加やコーディング、カバレッジの構築などが簡単にできる協力な新機能が登場した。
• 所有権モデルを分散化し、リソースレイヤーのレジストリを作成し、サービスチームがこれらのリソースを構築できるようにしました。
• 様々なサービスチームが作成できるようにすると次の問題がでてきました。一貫性というものでした。
• 標準化で重要なのは、一貫性です。
• 確認用のレジストリを作成しました。
• CloudFormationレジストリは、一貫したリソースの定義を提供します。スキーマベースのモデルで、すべての単一のリソースは、彼らがこの標準仕様を満たすことを保証するために厳格な契約です。
• そのため、ドリフト検知やリソーシングなど、よりエキサイティングなロードマップを作成することができます。リソースがすべて同じ方法で構築されたモデルであるため、自動トラフィック生成などの機能が機能するようになりました。
• CDKをお使いの方は多いと思いますが、多くの追加サービスをライトアップすることができます。
• 標準のリソースモデルで、CDKのコンストラクトを自動生成することができます。AWS configはCloudFormationのリソースモデルで、configのサポートを提供します。
• 一貫したリソースモデルを持つようになると、様々なマジックが起こります。これを私たちは「標準化」と呼んでいます。
• これは、私たちが約1年半かけて取り組んできたことです。
• 完全な後方互換性がなければなりません。
• 私たちは、壊れるような変更を導入しません。私たちは標準モデルにますます多くのリソースが移行することには関与していません
• 標準的なリソース・モデルができれば、何ができるかを知ってほしい。

AWS Cloud Control API

• 昨年、クラウドコントロールAPIというものを立ち上げました。
• クラウドコントロールAPIは一つの標準的なAPIインタフェースを提供します。
• create read update delete listという一つの標準的なセットを持っています。
• このレジストリ・モデルをサポートするすべてのサービスに対して、操作や制御を行うことができます。
• これは基礎となるAPIを抽象化します。

New coverage updates

• 1つ紹介したいのは、Oraganizations の機能です。これは、お客様が長らくの間求めていたものです。
• 自動化をサポートしていない残りのいくつかのサービスにおいて、CloudFormationを使用して、Oraganizationユニット、ポリシーの管理などができるようになりました。
• 50の新しいリソース・プロバイダーを発表することにしました。Data DogやMongoといった既存のプロバイダーに加えて、CloudflareやGitLab、PagerDutyといったソリューションもサポートするようになりました。
• これらはカスタムリソースで作成するものとは違い、標準的なリソースと同じように使用することができます。

Organizational trends in IaC

• 組織として、人々がITインフラストラクチャをコードとして使用することをサポートし、多くの人々がその利点を本当に活用できるようにする方法についてです。
• CloudFormation CDKは、インフラストラクチャのコード利用を提供することができます。
• 現在のトレンドやサービスチーム内で話題になっている分野について少しお話します。
• protonやService Catalogなどのサービスなどの、いくつか最新情報を提供したいと思います。

Platform enginerring is emrgin to dirve value

• プラットフォーム・エンジニアリングという考えについて
• セキュリティや導入のベストプラクティスを備えた正しいInfrastructure as Codeの構築により、正しい相互作用モデルを作成必要があるという考え方によって推進していく
• プラットフォーム・エンジニアリング・チームは、標準環境を構築し、ベスト・プラクティスを構築しています
• 自分の組織とオペレーションに、ビジネスに最適なオペレーションを反映させるにはどうしたらいいかを考えて欲しい
• 開発者とインフラストラクチャーの担当者が最適な技術を用いてCI/CDなどの運用方法を考慮する必要がある
• Amplify, Service catalog, Protonは、それぞれ異なる種類のオペレーションモデルをサポートしています。
• Amplifyは、フロントエンドやモバイルアプリの開発者がインフラをコードとして考える必要がないように設計されている
• サービスカタログは、インフラコードのテンプレートを作っている人が、カタログに登録することができます。
• protonでは、インフラをコードテンプレートとして記述し、CI/CDパイプラインと組み合わせて、バージョン管理やデプロイメントを長期的に行うことができます。

What is GitOps ?

• GitOpsはソフトウェア・アプリケーションのコードを中央の git リポジトリで管理し、マージ・リクエストのプロセスを使用してプル・リクエストを発行して更新するという考え方で、インフラストラクチャをコードとして管理する方法としてますます注目されてきています
• 標準的なプロセスを自動化することができ、単一ソースを提供して、デプロイされているものに対する可視性と信頼性を高めることができる

Empowering app developers to infuluence infra

• アプリケーション開発者が運用チームとより緊密に連携することで、インフラの設計とデプロイの方法に大きな影響を与えています。
• CDKがより一般的になり、組織内でより多くのアプリケーション開発者がコードを書き、インフラを再構築できるようになったことを考えると、適切なプロセスが必要なことを再確認したい
• 開発者がインフラやコードの変更を本番環境に安全に持ち込めるように、適切なチームや運用チームが彼らをサポートし、優れたツールやデプロイメントフローを提供するにはどうしたらよいか

Meeting the neeeds of all personas

• 自分のアプリケーションに合ったインフラを設計し、そのインフラがどのようなものであるかについてよく理解している人たちが、自分の好きなツールを開発できるようにするには、どうしたらよいかを考える

• 基本的なツールセットと、インフラストラクチャを構築して開発する方法は何か、それはコードであり、チームが持つ専門知識とスキルを反映したものであるということ
• YAML/JSONで作成している人もいるが、AWS CDKで作成しているお客様が増えてきている

• CFN Language Discussion
• 意見交換の場ができた
• CDK Construct Tree View
• 関係が見えにくかったCDKとCloudFormationのマッピングがみれるようになった

• 私たちは、 infrastructure as code のベストプラクティスやテンプレートを体系化し、ゴールデンパスと呼ぶべきものを構築することで、よりセルフサービス・モデルに移行することをチームに推奨している

• ゴールデンパスでは、セルフサービステンプレートとCI/CDパイプラインと統合するインターフェースを設定し、アプリケーションをインフラにデプロイするためのポリシー、ガバナンス、セキュリティのコンポーネントをより自動化するようにしました

Managed Service suppoert for best practices

• さまざまな種類のインフラストラクチャー・コード・ツールのサポートが今年は行われました。CloudFormationに加えて、TerraFormやPulumiも使えるようになりました。

Right level of abstraction for your team

• ツールを使って適切なレベルの標準をサポートする必要がある
• 組織内の専門性に合った適切なツール群を見つけることが重要

IaC is a key point for preventative governance

• IaC で標準化すれば、セキュリティ、コンプライアンス、運用のベストプラクティスなどを実施する場所として、非常に直観的に理解できるようになります。

Consistent policy definition enforced across lifecycle

• IaCでポリシーをコードとして残すという考え方は、以前からありましたが、実際にこれを採用するお客様が増えてきています。
• 一番大変だったのは、実際にポリシーを書くことです。
• リソースのライフサイクルに合わせて、ガードルールを記載し、検査を行う。

Opinionated purpose-build controls for 28 AWS services(preview)

• Control Tower で、CloudFormationを使ってコントロールのセットをオーサリングする機能です。

AWS IaC year ahead

• 来年について考えていることの方向性について
• サポートするリソースの対象範囲を広げること、リソースレジストリ、Cloud Control API
• パフォーマンス改善を行う
• CDKを採用する企業が増えており、こちらのサポートもすすめていく
• デプロイメント状況の可視化

感想

ここ最近のCloudFormation等のアップデート状況をふりかえりつつ、AWS のInfrastructure as Codeとはどのような位置づけにいるのか理解できました。
CloudFormationのコードはCDK等に置き換わることも今後はふえていくかとも思いますが、あくまでCloudFormationまた、Cloud Control APIの上になりたっていること。
また、CloudFormationの機構(コード）をつかって、CI/CDやセキュリティ等のポリシーのガバナンスにもAWSは使用していくという方向性がわかるセッションだったかと思います。